1. Field of the Invention
The present invention relates generally to a Broadband Wireless Access (BWA) communication system, and in particular, to a system and method for supporting soft handover in a BWA communication system using an Orthogonal Frequency Division Multiple Access (OFDMA) scheme.
2. Description of the Related Art
Extensive research into a 4th generation (4G) communication system, which is the next generation communication system, is being conducted to provide users with services having various Qualities-of-Service (QoSs) at a data rate of about 100 Mbps. Generally, the current 3rd generation (3G) communication system supports a data rate of about 384 Kbps in an outdoor channel environment that provides only relatively poor channel conditions, and supports up to a data rate of 2 Mbps in an indoor channel environment that provides relatively good channel conditions. A wireless Local Area Network (LAN) system and a wireless Metropolitan Area Network (MAN) system generally support a data rate of 20 to 50 Mbps.
Presently, extensive research of the 4G communication system is being conducted to develop a new communication system capable of supporting mobility and QoS in the wireless LAN system and the wireless MAN system, both of which guarantee a relatively high data rate, in order to support a high-speed service that the 4G communication system aims to provide. The typical communication systems include an Institute of Electrical and Electronics Engineers (IEEE) 802.16a communication system and an IEEE 802.16e communication system. The wireless MAN system is suitable to support a high-speed communication service because it has broad coverage and supports a high data rate. However, the wireless MAN system does not take into consideration the mobility of users, or subscriber stations, or handover due to fast movement of the subscriber stations.
FIG. 1 is a diagram illustrating a configuration of a conventional IEEE 802.16e communication system. Referring to FIG. 1, the IEEE 802.16e communication system has a multicell structure, i.e. has a cell 100 and a cell 150, and includes a base station (BS) 110 managing the cell 100, a BS 140 managing the cell 150, and a plurality of mobile stations (MSs) 111, 113, 130, 151 and 153. Signal exchange between the base stations 110 and 140 and the MSs 111, 113, 130, 151 and 153 is achieved using an Orthogonal Frequency Division Multiplexing (OFDM) scheme or an Orthogonal Frequency Division Multiple Access (OFDMA) scheme. Among the MSs 111, 113, 130, 151 and 153, the MS 130 is located in a boundary region of the cell 100 and the cell 150, i.e. a handover region. In order to support the mobility of MS 130, it is necessary to support a handover for the MS 130.
The wireless MAN system, which is a BWA communication system, has broader coverage and supports a higher data rate as compared to the wireless LAN system. An IEEE 802.16a/d communication system is known as a communication system employing the OFDM/OFDMA scheme to support a broadband transmission network to physical channels for the wireless MAN system. The IEEE 802.16a/d communication system is a typical example of a BWA communication system using the OFDM/OFDMA scheme.
The IEEE 802.16a/d communication system, as it applies the OFDM/OFDMA scheme to the wireless MAN system, can support high-speed data transmission by transmitting physical channel signals using a plurality of subcarriers. In addition, an IEEE 802.16e communication system is a system improved to support the mobility of subscriber stations in the IEEE 802.16a/d communication system. That is, both of the IEEE 802.16a/d communication system and the IEEE 802.16e communication system are BWA communication systems using the OFDM/OFDMA scheme.
FIG. 2 is a diagram illustrating an uplink/downlink frame structure in a conventional BWA communication system using an OFDM/OFDMA scheme. Referring to FIG. 2, the uplink/downlink frame structure includes a preamble part, a broadcast control part, and a data transmission part. The preamble part transmits a synchronization (SYNC) signal used for acquiring SYNC between a BS and a subscriber station, i.e. a preamble sequence. The broadcast control part includes a downlink MAP (DL-MAP) part and an uplink MAP (UL-MAP) part. The DL-MAP part is a part through which a DL-MAP message is transmitted, and information elements (IEs) included in the DL-MAP message are shown in Table 1. The data transmission part can be divided into partial-usage-of-subchannels (PUSC) and full-usage-of-subchannels (FUSC). The PUSC part and the FUSC part can be distinguished in the same frame on a time-division basis.
The PUSC scheme allocates only particular subchannels from among all of the subchannels for each sector. It is possible to avoid inter-sector interference by allocating different PUSC subchannel parts to two adjacent sectors.
However, the FUSC scheme allocates all of the subchannels to every sector in every cell. Therefore, the FUSC scheme corresponds to operating at a frequency reuse factor of ‘1’. The FUSC scheme, although it can use all of the subchannels in every sector, creates a different subcarrier set for subchannels for each sector in order to minimize inter-subchannel interference of each sector. That is, the FUSC subchannels should be designed such that a hit probability that subcarriers for the subchannels overlap each other should be minimized. In order to support soft handover to a subscriber station, two sectors should be able to allocate the same subchannels. However, it is impossible for the subscriber station to perform soft handover with a subchannel or message format defined in the current IEEE 802.16 standard.
TABLE 1SyntaxSizeNotesDL-MAP_Message_Format( ) { Management Message Type=2 8 bits PHY Synchronization FieldVariableSee appropriatePHY specification DCD Count 8 bits Base Station ID18 bits Begin PHY Specific Section {See applicablePHY section  for(i=1; 1<=n; i++) {For each DL-MAPelement 1 to n   DL-MAP_IE( )variableSee correspondingPHY specification   }  }  if!(byte boundary) {  Padding Nibble 4 bitsPadding toreach byte boundary }}
As shown in Table 1, a DL-MAP message includes a plurality of IEs, i.e. a Management Message Type indicating a type of the transmission message, a physical (PHY) Synchronization Field which is set according to a modulation scheme and a demodulation scheme applied to a physical channel for SYNC acquisition, a DCD Count indicating a count that depends from a change in the configuration of a Downlink Channel Description (DCD) message including a downlink burst profile, a Base Station ID indicating a base station identifier (ID), and a ‘Number of DL-MAP Elements n’ indicating the number of elements succeeding the Base Station ID. In particular, although not shown in Table 1, the DL-MAP message includes information of the ranging codes allocated to each of rangings described below.
Similarly, the UL-MAP part is a part through which a UL-MAP message is transmitted, and IEs included in the UL-MAP message are shown in Table 2.
TABLE 2SyntaxSizeNotesUL-MAP_Message_Format( ) { Management Message Type=3 8 bits Uplink Channel ID 8 bits UCD Count 8 bits Allocation Start Time32 bits Begin PHY Specific Section {See applicable PHY section  for(i=1; 1<=n; i++) {For each UL-MAPelement 1 to n   UL-MAP_IE( )variableSee corresponding PHYspecification  } } if!(byte boundary) {  Padding Nibble 4 bitsPadding to reachbyte boundary }}
As shown in Table 2, the UL-MAP message includes a plurality of IEs, i.e. a Management Message Type indicating a type of the transmission message, an Uplink Channel ID indicating an uplink channel ID used, a UCD Count indicating a count that depends from a change in the configuration of an Uplink Channel Descript (UCD) message including an uplink burst profile, and a ‘Number of UL-MAP Elements n’ (not shown in Table 2) indicating the number of elements succeeding the UCD Count. The uplink channel ID is uniquely allocated in a media access control (MAC) sublayer.
The data transmission part corresponds to time slots, which are allocated to subscriber stations on a time division multiplexing (TDM)/time division multiple access (TDMA) basis. The base station transmits broadcast information to be broadcasted to its subscriber stations though a DL-MAP part 211 of the downlink frame, using a predetermined center carrier. Upon power on, the subscriber stations each monitor all of the frequency bands preset thereto and detect a pilot channel signal having the highest strength, i.e. the highest pilot carrier-to-interference and noise ratio (CINR). Each subscriber station determines a BS that transmitted the pilot channel signal having the highest pilot CINR as a BS to which it currently belongs, and can acquire control information for controlling its own uplink and downlink, and information on actual data transmission/reception points by analyzing a DL-MAP part and an UL-MAP part of a downlink frame transmitted from the BS.
A format of the UCD message is shown in Table 3.
TABLE 3SyntaxSizeNotesUCD-Message_format( ) { Management Message Type=08 bits Uplink channel ID8 bits Configuration Change Count8 bits Mini-slot size8 bits Ranging Backoff Start8 bits Ranging Backoff End8 bits Request Backoff Start8 bits Request Backoff End8 bits TLV Encoded Information for the overall channelVariable Begin PHY Specific Section {  for(i=1; i<n; i++)   Uplink_Burst_DescriptorVariable  } }}
As shown in Table 3, the UCD message includes a plurality of IEs, i.e. a Management Message Type indicating a type of the transmission message, an Uplink Channel ID indicating an uplink channel ID, a Configuration Change Count counted in BS, a Mini-slot Size indicating a size of mini-slots in an uplink physical channel, a Ranging Backoff Start indicating a start point of a backoff using an initial ranging (i.e. indicating a size of an initial backoff window using an initial ranging), a Ranging Backoff End indicating an end point of a backoff using the initial ranging (i.e. indicating a size of a final backoff window), a Request Backoff Start indicating a start point of a backoff for contention data and requests (i.e. indicating a size of an initial backoff window), and a Request Backoff End indicating an end point of a backoff for contention data and requests (i.e. indicating a size of a final backoff window). The backoff value indicates the type of waiting time value for which a subscriber station should wait for the next ranging upon its failure in rangings described below, and when a subscriber station fails in ranging, a base station should transmit to the subscriber station the backoff value, which is information of a time for which it should wait for the next ranging. For example, if a value determined from the Ranging Backoff Start and the Ranging Backoff End is ‘10’, the subscriber station should perform the next ranging after passing 210=1024 ranging opportunities by a truncated binary exponential backoff algorithm.
The DL-MAP message is periodically broadcast from a base station to all of the subscriber stations, and an occasion on which a subscriber station can continuously receive the DL-MAP message is referred to as “sync is detected.” That is, subscriber stations receiving the DL-MAP message can receive all messages transmitted through a downlink channel.
As described above with reference to Table 3, when a subscriber station fails to access a base station, the base station transmits to the subscriber station the UCD message including the backoff information.
In a process of performing the ranging, the subscriber station transmits a ranging request (RNG-REQ) message to the base station, and the base station receiving the RNG-REQ message transmits to the subscriber station a ranging response (RNG-RSP) message including the above-stated information in order to correct the frequency, time and transmission power.
A format of the RNG-REQ message is shown in Table 4.
TABLE 4SyntaxSizeNotesRNG-REQ_Message_Format( ) { Management Message Type=48 bits Downlink Channel ID8 bits TLV Encoded InformationvariableTLV specific}
In Table 4, a Downlink Channel ID indicates a downlink channel ID included in an RNG-REQ message that the subscriber station has received through the UCD message.
A format of the RNG-RSP message corresponding to the RNG-REQ message of Table 4 is shown in Table 5.
TABLE 5SyntaxSizeNotesRNG-RSP_Message_Format( ) { Management Message Type=58 bits Uplink Channel ID8 bits TLV Encoded InformationvariableTLV specific}
As described above, the IEEE 802.16a communication system takes into consideration only fixed subscriber stations, i.e. does not consider the mobility of the subscriber stations, and considers only a unicell structure. However, the IEEE 802.16e communication system, as described above, is defined as a system that considers the mobility of subscriber stations in the IEEE 802.16d communication system. Therefore, the IEEE 802.16e communication system should consider the mobility of subscriber stations in a multicell environment. In order to provide for the mobility of the subscriber stations in the multicell environment, the subscriber stations and the base station essentially require a change in their operations due to the movement of the subscriber stations. extensive research into the handover of the subscriber stations is being performed taking into consideration the multicell structure in order to support the mobility of subscriber stations.
In the BWA communication system, a subscriber station receives preambles transmitted from a plurality of base stations. The subscriber station measures CINRs of the received preambles, and selects a BS corresponding to the highest CINR from among the measured CINRs. That is, the subscriber station (SS) selects a BS having the best reception state from among the base stations that have transmitted the preamble channels, thereby recognizing a base station to which it currently belongs. The base station having the best reception state will be referred to as a “serving BS.”
The serving BS transmits a Neighbor Advertisement (MOB_NBR-ADV) message to the SS. A format of the MOB_NBR-ADV message is shown in Table 6.
TABLE 6SyntaxSizeNotesMOB_NBR-ADV_Message_Format( ) { Management Message Type=49 8 bits Operator ID24 bitsUnique IDassignedto the operator N_NEIGHBORS 8 bits For (j=0; j<N_NEIGHNORS; j++) {  Neighbor BS-ID48 bits  Physical Frequency32 bits  Configuration Channel Count 8 bitsIncremented eachtime theinformationfor the associatedneighbor BS haschanged.  Hysteresis threshold 8 bits  MAHO report period 8 bits  TLV  Encoded  NeighborVariableTLV specificinformation }}
As shown in Table 6, the MOB_NBR-ADV message includes a plurality of IEs, i.e. a Management Message Type indicating a type of the transmission message, a Configuration Change Count indicating the number of changes in the configuration, an N_NEIGHBORS indicating the number of neighbor BSs, a Neighbor BS-ID indicating IDs of the neighbor BSs, a Physical Frequency indicating the physical channel frequencies for the neighbor BSs, and a TLV (Type/Length/Value) Encoded Neighbor Information indicating the other information related to the neighbor BSs. In addition, the MOB_NBR-ADV message includes a Hysteresis threshold on which an SS can issue a handover request, and a MAHO (Mobile Assisted Handover) report period for periodical scan report.
The SS, receiving the MOB_NBR-ADV message, transmits a Scanning Interval Allocation Request (MOB_SCN-REQ) message to the serving BS when it desires to scan CINRs of preambles transmitted from its neighbor BSs. The time when the SS issues a scan request is not directly related to a CINR scanning operation for the preamble signals, so a detailed description thereof will be omitted.
A format of the MOB_SCN-REQ message is shown in Table 7.
TABLE 7SyntaxSizeNotesMOB_SCN-REQ_Message_Format( ) { Management Message Type=? 8 bits Scan Duration16 bitsUnits are frames.}
As shown in Table 7, the MOB_SCN-REQ message includes a plurality of IEs, i.e. a Management Message Type indicating a type of the transmission message, and a Scan Duration indicating scan duration for which an SS desires to scan CINRs of preamble signals transmitted from the neighbor BSs. The Scan Duration is created on a frame-by-frame basis. In Table 7, the Management Message Type for transmission of the MOB_SCN-REQ message is currently undefined (Management Message Type=undefined).
The serving BS, receiving the MOB_SCN-REQ message, transmits to the SS a MOB_SCN-RSP message including information to be scanned by the SS. A format of the MOB_SCN-RSP message is illustrated in Table 8.
TABLE 8SyntaxSizeNotesMOB_SCN-RSP_Message_Format( ) { Management Message Type=51 8 bits CID16 bitsbasic CID of theMSS Duration12 bitsin frames Start Frame 4 bits}
As shown in Table 8, the MOB_SCN-RSP message includes a plurality of IEs, i.e. a Management Message Type indicating a type of the transmission message, a CID indicating a connection ID of the SS that transmitted the MOB_SCN-REQ message, and a Duration indicating the scan duration. In Table 8, Management Message Type for transmission of the MOB_SCN-RSP message is currently undefined (Management Message Type=undefined), and the scan duration indicates the duration for which the SS performs the pilot CINR scanning.
The SS, receiving the MOB_SCN-RSP message including the scanning information, scans for pilot CINRs of neighbor BSs that it has recognized through the MOB_NBR-ADV message according to the scanning information parameters.
In the IEEE 802.16e communication system, in order to support a handover, an SS should measure the CINRs of the preamble signals transmitted from its neighbor BSs and its serving BS to which it currently belongs. When a CINR of the preamble signal transmitted from the serving BS is less than the CINRs of the preamble signals transmitted from the neighbor BSs, the SS sends a handover request to the serving BS. Herein, for convenience, “measuring a CINR of a preamble signal” will be referred to as “scanning a CINR of a preamble signal.”
FIG. 3 is a diagram illustrating a sector structure in a BWA communication system using an OFDM/OFDMA scheme. Referring to FIG. 3, one base station is divided into three sectors, and each sector can be distinguished by beam forming by sectorized antennas. All of the sectors belonging to the same BS use the same center frequency, and each sector uses a unique divided bandwidth with different subchannel sets. However, the specification does not specify whether this subchannel concept divides only the data part or divides the full band into three equal parts.
FIG. 4 is a signaling diagram illustrating a hard handover process initiated at the request of an MSS in a conventional IEEE 802.16e communication system. Referring to FIG. 4, a serving BS 440 transmits a MOB_NBR-ADV message to a mobile station (MS) 400 (Step 411). The MS 400 receiving the MOB_NBR-ADV message transmits a MOB_SCN-REQ message to the serving BS 440 to request a scan of the CINRs of the pilot signals received from its neighbor BSs (Step 413). The time when the MSS 400 issues a scan request is not directly related to the pilot CINR scanning operation, so a detailed description thereof will be omitted. The serving BS 440 receiving the MOB_SCN-REQ message transmits to the MS 400 a MOB_SCN-RSP message including information to be scanned by the MS 400 (Step 415). The MS 400, receiving the MOB_SCN-RSP message including the scanning information, performs the CINR scanning on the pilot signals according to certain parameters, i.e. scan duration, included in the MOB_SCN-RSP message, for neighbor BSs recognized through the MOB_NBR-ADV message (Step 417).
After the completion of the scanning of the CINRs of the pilot signals received from the neighbor BSs, if the MS 400 determines to change its serving BS (Step 419), i.e. determines to replace the current serving BS with a new serving BS, the MS 400 transmits a Mobile Station Handover Request (MOB_MSHO-REQ) message to the serving BS 440 (Step 421). The format of the MOB_MSHO-REQ message is shown in Table 9.
TABLE 9SyntaxSizeNotesMOB_MSHO-REQ_Message_Format( ) { Management Message Type=53  For (j=0; j<N_Recommended; j++) {N_Recom-mended canbe derivedfrom the knownlength of themessage   Neighbor BS-ID48 bits   BS CINR mean 8 bits   Service level prediction 8 bits   Estimated HO start 8 bits }  Estimated HO start 8 bitsThe estimated HOtime shall bethe time for therecommendedtarget BS}
As shown in Table 9, the MS_MSSHO-REQ message includes a plurality of IEs, i.e. a Management Message Type indicating a type of the transmission message, and an N_Recommended indicating the number of a scanning result of an MS. The N_Recommended, as shown in Table 9, includes a Neighbor BS-ID indicating IDs of neighbor BSs, a BS CINR mean indicating a CINR of a pilot signal for each of the neighbor BSs, and a Service level prediction indicating a predicted service level that the neighbor BSs will provide to an MS. In addition, the N_Recommended includes an Estimated HO start parameter indicating an estimated time when the handover will occur.
Upon receiving the MOB_MSHO-REQ message transmitted from the MS 400, the serving BS 440 acquires a target BS list from the N_Recommended information in the MOB_MSHO-REQ message (Step 423). The serving BS 440 transmits the Handover Notification (HO_NOTIFICATION) messages to the neighbor BSs belonging to the possible target BS list (Steps 425 and 427). It is assumed herein that the neighbor BSs included in the target BS list include a target BS#1 460 and a target BS#2 480. A format of the HO_NOTIFICATION message transmitted from the serving BS 440 to the target BSs 460 and 480 is shown in Table 10.
TABLE 10FieldSizeNotesGlobal Header152 bit For (j=0; j<Num_Records; j++) {  MS unique identifier 48 bit48-bit unique identifierused by MS (asprovided bythe MSS or bythe I-am-host-ofmessage)  Estimated Time to HO 16 bitIn millisecond, relativeto the time stamp. Avalue of 0 indicatesthat the estimatedtime is unknown.  Required BW 8 bitBandwidth which isrequired by MSS(to guaranteeminimum packetdata transmission)  Required QoS 8 bitName of ServiceClass representingAuthorizedQoSParamSet} Security fieldTBDA means toauthenticatethis message CRC field 32 bitIEEE CRC-32
As shown in Table 10, the HO_NOTIFICATION message includes a plurality of IEs, i.e. an MS unique identifier indicating an ID of an MS that requests a handover to the target BS#1 460 or the target BS#2 480, an Estimated Time to HO indicating an estimated time when the handover will start, a Required BW indicating a bandwidth that the MS requires from a neighbor BS which will become a new serving BS, and a Required QoS indicating a QoS level desired by the MS. The bandwidth and QoS level required by the MS are equal to the information recorded in the Service Level Prediction field of the MOB_MSHO-REQ message shown in Table 9.
Upon receiving the HO_NOTIFICATION messages transmitted from the serving BS 440, the target BS#1 460 and the target BS#2 480 each transmit a Handover Notification Response (HO_NOTIFICATION-RESPONSE) message to the serving BS 440 in response to the HO_NOTIFICATION messages (Steps 429 and 431). The formation of the HO_NOTIFICATION-RESPONSE message is shown in Table 11.
TABLE 11FieldSizeNotesGlobal Header152 bits For(j=0; j<Num Records; j++) {  MS unique identifier 48 bits48 bit unique identifier used by MS(as provided by the MSS or by the I-am-host-of message)  BW Estimated 8 bitsBandwidth which is provided by BS(to guarantee minimum packet datatransmissions) TBD how to set thisfield  QoS Estimated 8 bitsQuality of Service levelUnsolicited Grant Service (UGS)Real-time Polling Service (rtPS)Non-real-time Polling Service(nrtPS)Best Effort  ACK/NACK 8 bitsAcknowledgement or Negativeacknowledgement1 is Acknowledgement whichmeans that the neighbor BS acceptsthe HO-notification message fromthe Serving BS0 is Negative Acknowledgementwhich means that the neighbor BSmay not accept the HO-notificationmessage from the Serving BS}security fieldTBDA means to authenticate this messageCRC field 32 bitsIEEE CRC-32
As shown in Table 11, the HO_NOTIFICATION-RESPONSE message includes a plurality of IEs, i.e. an MS unique identifier indicating an ID of an MSS that desires to perform the handover to the target BSs, an ACK/NACK indicating whether the target BSs can accept the handover request from the MS, a BW Estimated indicating a bandwidth that the target BSs can provide to the MS, and a QoS Estimated indicating a QoS level that the target BSs can provide.
If the HO_NOTIFICATION-RESPONSE messages are received from the target BS#1 460 and/or the target BS#2 480 in steps 429 and 431, the serving BS 440 selects target BSs that can provide the bandwidth and QoS level required by the MS 400 when the MS 400 moves thereto. For example, in step 429, the target BS#1 460 transmits the HO_NOTIFICATION-RESPONSE message including information indicating that it can provide a low QoS level to the MS 400, and in step 431, the target BS#2 480 transmits the HO_NOTIFICATION-RESPONSE message including information indicating that it can provide the same QoS level to the MS 400. In step 433, the serving BS 440 selects the target BS#2 480 that can provide the same QoS level, and transmits a Handover Notification Confirm (HO_NOTIFICATION_CONFIRM) message in response to the HO_NOTIFICATION-RESPONSE message from the selected target BS#2 480. The format of the HO_NOTIFICATION_CONFIRM message is shown in Table 12.
TABLE 12FieldSizeNotesGlobal Header152 bitsFor(j=0; j<Num Records;j++) { MS unique identifier 48 bits48 bit universal MACaddress of the MS (as provided to theBS on the RNG-REQ message) BW Estimated 8 bitsBandwidth which is provided by BS (to guarantee minimumpacket data transmissions)TBD how to set this field QoS Estimated 8 bitsQuality of Service levelUnsolicited Grant Service (UGS)Real-time Polling Service (rtPS)Non-real-time Polling Service(nrtPS)Best Effort}security fieldTBDA means to authenticatethis messageCRC field 32 bitsIEEE CRC-32
As shown in Table 12, the HO_NOTIFICATION_CONFIRM message includes a plurality of IEs, i.e. an MS unique identifier indicating an ID of an MS 400 that requests a handover to the selected target BSs, a BW Estimated indicating a bandwidth that the MS 400 can receive from the target BSs, and a QoS Estimated indicating a QoS level that MS 400 can receive from the target BSs.
After selecting the target BSs in step 433, the serving BS 440 transmits a Handover Response (MOB_HO-RSP) message to the MS 400 in response to the MOB_MSHO-REQ message (Step 435). The format of the MOB_HO-RSP message is shown in Table 13.
TABLE 13SyntaxSizeNotesMOB_BSHO-RSP_Message_Format( ) { Management Message Type=54 8 bits Estimated HO start 8 bits  For(j=0; j<N_Recommended; j++) {Neighbor base stations shall bepresented in an order such thatthe first presented is the onemost recommended and the lastpresented is the leastrecommended.N_Recommended can bederived from the known lengthof the message.   Neighbor BS-ID48 bits   Service level prediction 8 bits }}
As shown in Table 13, the MOB_HO-RSP message includes a plurality of IEs, i.e. a Management Message Type indicating a type of the transmission message, an Estimated HO start indicating an estimated time when an handover process will start, and an N_Recommended indicating a target BS selection result of the serving BS. The N_Recommended, as shown in Table 13, includes a Neighbor BS-ID indicating the IDs of the selected target BSs, and a Service level prediction indicating a predicted service level that the selected target BSs will provide to the MS 400.
Upon receiving the MOB_HO-RSP message, the MS 400 selects a target BS to which it will perform a handover to, depending on the N_Recommended information included in the MOB_HO-RSP message. After selecting the target BS, the MS 400 transmits a Handover Indication (MOB_HO_IND) message to the serving BS 440 to the serving BS 440 in response to the MOB_HO-RSP message (Step 437). The format of the MOB_HO_IND message is shown in Table 14.
TABLE 14SyntaxSizeNotesMOB_HO_IND_Message_Format ( ) { Management Message Type=56 8 bits reserved 6 bitsShall be set to zero. HO_IND_type 2 bits00: serving BSrelease01: HO cancel10: HO reject11: Reserved Target_BS_ID48 bitsApplicable onlywhen HO_INDtype is set to 00. HMAC Tuple21 bytes}
As shown in Table 14, the MOB_HO_IND message includes a plurality of IEs, i.e. a Management Message Type indicating a type of the transmission message, a Target_BS_ID indicating an ID of a target BS selected by the MS, and a HO_IND_type used when the MS informs the serving BS that it will release its connection for handover, or when the MS cancels or rejects the handover.
It is assumed in FIG. 4 that the MS 400 transmits the MOB_HO_IND message with the HO_IND_type=‘00’ to the serving BS 440. The serving BS 440 releases the link to the MS 400 (Step 439). After transmitting the MOB_HO_IND message, the MS 400 starts a handover process to the target BS to which it will perform handover, i.e. the target BS#2 480.
The MS 400 can be allocated a contention-free ranging connection interval by receiving DL-MAP and UL-MAP, both of which includes a Fast ranging IE shown in Table 15. The MS 400 performs contention-free ranging with the target BS#2 480 (Steps 443 and 445). After completion of the ranging process, the MS 400 performs data exchange with the new serving BS 480 (Step 447). The Fast ranging IE is shown in Table 15.
TABLE 15SyntaxSizeNotesFast_UL_ranging_IE { Extended UIUC 4 bits MAC address48 bitsMSS MAC address as provided on the RNG-REQmessage on initial system entry. UIUC 4 bitsUIUC≠15. A four-bit code used to define the typeof uplink access and the burst typeassociated with that access. OFDM Symbol offset10 bitsThe offset of the OFDM symbol in which theburst starts, the offset value is defined in units of OFDM symbols and is relevant to theAllocation Start Time field given in the UL-MAP message. Subchannel offset 6 bitsThe lowest index OFDMA subchannel used forcarrying the burst, starting from subchannel 0. No. OFDM Symbols10 bitsThe number of OFDM symbols that are used tocarry the UL Burst No. Subchannels 6 bitsThe number OFDMA subchannels withsubsequent indexes, used to carry the burst. Reserved 4 bits}
As shown in Table 15, the Fast ranging IE includes, as information for fast ranging, a UIUC indicating a MAC address of the MS and a modulation/demodulation scheme to be used in an uplink, an OFDM Symbol offset indicating a ranging region, a Subchannel offset indicating a subchannel offset, a No.OFDM Symbols indicating the number of OFDM Symbols, and a No.Subchannels indicating the number of Subchannel.